Problem

WithDatastoreHandlerMethods::create() does an INSERT then immediately reads the row back to hydrate the returned model. On any host with a write/read-split router in front of MySQL/MariaDB (ProxySQL, MaxScale, RDS Proxy, Aurora, Cloudways Autonomous, etc.), the autocommit INSERT lands on master and the autocommit SELECT is allowed to be routed to a read-replica that hasn't yet received the write. The result is a RecordNotFoundException thrown from a successful insert.

This is a property of distributed systems, not of MariaDB specifically. Any future PHPNomad integration against an eventually-consistent backend (Postgres + pgpool, MongoDB with read preferences, Cassandra, Elasticsearch, REST behind a CDN) would exhibit the same failure shape.

Production reproduction

Reproduced on a customer's actual production environment (Cloudways Autonomous, MariaDB 10.11.5 behind a routed K8s service):

Every failure had the same client-side CONNECTION_ID(), with LAST_INSERT_ID() returning the correct id, recovering within 10–50ms. The router pins clients to one backend during a transaction (mandatory for txn correctness), which is why every transactional mode passed cleanly.

Approach

Most ORMs and platforms (WordPress core, Eloquent, Doctrine, ActiveRecord) avoid this race by not reading back after a write — they construct the model from the data the caller passed plus the new identity, and trust their in-memory representation. This PR brings PHPNomad in line with that pattern.

What changed

Column gains an optional withPhpDefault() setter

$column = (new Column('createdAt', 'TIMESTAMP', null, 'NOT NULL DEFAULT CURRENT_TIMESTAMP'))
    ->withPhpDefault(static fn () => (new DateTimeImmutable())->format('Y-m-d H:i:s'));

The callable is invoked at create() time for any column the caller didn't provide. The DB-side DEFAULT stays in place as belt-and-suspenders for inserts that bypass the framework.

DateCreatedFactory and DateModifiedFactory use it

Both factories now provide a phpDefault that returns the current MySQL-format timestamp. Existing column DDL is unchanged.

create() hydrates from attributes + ids

$attributes = $this->applyPhpDefaults($attributes);
$ids = $this->serviceProvider->queryStrategy->insert($this->table, $attributes);
$result = $this->modelAdapter->toModel(Arr::merge($attributes, $ids));
$this->cacheItems([$result]);
$this->serviceProvider->eventStrategy->broadcast(new RecordCreated($result));

No post-insert SELECT. The cache pre-warm lands the model under the same key the existing getModels() flow would have used, so subsequent reads transparently short-circuit through the cache.

Contract change

Any column whose value should appear in the post-create() model must either:

• be passed by the caller, or
• come from a column factory that provides a phpDefault.

Columns relying solely on a DB-side DEFAULT (without a matching phpDefault), trigger-set values, and generated columns won't be reflected in the in-memory model. Callers that need those values should refresh explicitly. In practice this is a non-event for existing PHPNomad consumers because all framework-provided default columns flow through the factories updated here.

Why this is better than the writer-consistent approach

The previous attempt (#21's predecessor, plus the closed PRs in phpnomad/wordpress-integration#30 and phpnomad/mysql-db-integration#12) wrapped post-write reads in a transaction or used a HyperDB hook to force master routing. That works but:

• adds latency to every create() even on hosts with no router
• has a serious nested-transaction footgun (silently commits a caller-owned outer transaction on MariaDB)
• only solves the problem for SQL backends with router awareness — useless against MongoDB/Cassandra/Elasticsearch/REST
• adds connection-pinning pressure on routers under load

Hydrating from attributes:

• zero overhead on every host (no transaction, no extra round-trip)
• architecturally eliminates the race rather than mitigating it
• works the same way against any future integration regardless of backend
• matches the pattern WordPress/Eloquent/Doctrine already use

Tests

• Column::withPhpDefault / getPhpDefault contract
• DateCreatedFactory and DateModifiedFactory produce a working phpDefault
• create() hydrates without calling query() (no readback)
• create() applies phpDefaults for missing columns
• Caller-provided values win over phpDefaults

PHPUnit 9.6.22
.............                                                     13 / 13 (100%)
OK (13 tests, 34 assertions)

PHPStan level 9 clean for the changed files. Pre-existing warnings on Column.php (about iterable type specs on the original variadic $attributes) are untouched.

Related

• Closes phpnomad/wordpress-integration#30 and phpnomad/mysql-db-integration#12 — those defensive PRs can stay closed; this addresses the underlying problem at the right layer.